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SYSTEM AND METHOD TO 
PROVIDE PPPOE CONNECTIVITY 
TO NON-PPPOE CLIENTS 

Background of the Invention 

[0001] The present invention relates generally to transmitting data between a client and 
an access concentrator using a Point-to-Point Protocol over Ethernet (PPPoE) session, 
and more particularly to providing a virtual PPPoE session between a client unable to 
support a PPPoE session and an access concentrator. 

! [0002] Internet service providers (ISPs) and other high-speed data access service 

providers face a number of challenges to integrating legacy networks and systems 
with upgraded last mile access technology and other infrastructure upgrades. 
Accordingly, a Point-to-Point Protocol over Ethernet (PPPoE) format has been 
developed to overcome many of these challenges. PPPoE typically allows multiple 
clients to connect to an access concentrator of an ISP or other service provider using a 
common gateway device, such as a digital subscriber line (xDSL) modem, a cable 
modem, a wireless access point, and the like. Additionally, PPPoE allows service 
providers to utilize access control and to track usage for billing purposes in a manner 
similar to dial-up services provided using PPP. So while providing for access control 
and billing services provided by typical PPP services, PPPoE further takes advantage of 
a relatively high-speed Ethernet network for communication between the one or more 
clients and the gateway device. 

[0003] However, while PPPoE provides many advantages, known PPPoE-enabled systems 
often have limited utility in certain instances. A particular disadvantage of these 
known systems is that in order to provide a PPPoE session between a client and an 
access concentrator, the client typically must be adapted to support PPPoE sessions, 
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either through software, hardware, or a combination thereof. However, it may be 
impractical or impossible for some clients to implement such software or hardware. 
For example, the resources of the client may be limited, the cost of the PPPoE 
software /hardware may be prohibitive, a PPPoE software/ hardware solution may not 
be available for a certain client, and the like. Accordingly, such non-PPPoE clients 
typically would be unable to take advantage of the benefits afforded by PPPoE. 

[0004] In view of the limitations of known PPPoE implementations, a system and a 

method for providing PPPoE connectivity to clients without PPPoE support would be 
advantageous. 

Summary of the Invention 

[0005] The disclosed technique mitigates or solves the above-identified limitations in 
known implementations, as well as other unspecified deficiencies in the known 
implementations. 

[0006] The present invention, in one embodiment, provides an interface to a client that is 
not enabled to support a PPPoE session, where the interface allows for the client to 
communicate with an access concentrator utilizing the PPPoE protocol. The interface 
can appear as an asynchronous transfer mode (ATM) interface that supports RFC 1483 
encapsulation, as an Ethernet interface, and the like. Likewise, in one embodiment, 
the present invention allows an application to attach to the bridge as an interface 
using a media access control (MAC) address different than the MAC addresses 
associated with the bridge. Likewise, in at least one embodiment, the present 
invention provides a common interface to both PPPoE-enabled clients and clients not 
able to support PPPoE. 

[0007] 

In at least one embodiment of the present invention, a method for providing data 
from a client to an access concentrator using a gateway, the method comprising the 
steps of receiving, at a gateway, a non-PPPoE frame from the client, wherein the non- 
PPPoE frame includes data intended for receipt by the access concentrator, 
encapsulating, at the gateway, the first non-PPPoE frame to generate a PPPoE frame, 
wherein the PPPoE frame includes the data intended for receipt by the access 
concentrator, and providing the PPPoE frame to the access concentrator from the 
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gateway. 



[0008] In another embodiment of the present invention a system is provided, the system 
comprising a first interface adapted to receive a first frame having a non-PPPoE 
format from a first client and to provide a second frame having a non-PPPoE format to 
the first client, and a second interface adapted to receive a third frame having a PPPoE 
format from an access concentrator and to provide a fourth frame having a PPPoE 
format to the access concentrator. The system further comprises a PPPoE stack 
adapted to encapsulate the first frame having a non-PPPoE format into the fourth 
frame having a PPPoE format, and wherein the PPPoE stack further is to deencapsulate 
the third frame having a PPPoE format into the second frame having a non-PPPoE 
format and a bridge coupled to the first interface and the second interface, wherein 
the bridge is adapted to provide the fourth frame to the second interface for output to 
the access concentrator and to provide the second frame to the first interface for 
output to the first client. The system additionally comprises an IP stack coupled to the 
PPPoE stack and the bridge, wherein the IP stack is adapted to route the first frame 
from the bridge to the PPPoE stack and to route the second frame from the PPPoE 
stack to the bridge and a frame reflector coupled to the PPPoE stack and the bridge, 
wherein the frame reflector is adapted to provide the fourth frame to the bridge from 
the PPPoE stack and to provide the first frame from the bridge to the PPPoE stack. 

[0009] One objective of the present invention is to allow simultaneous PPPoE connections 
to a PPPoE access concentrator from at least one client that is not enabled to support 
a PPPoE session and at least one client that is enabled to support a PPPoE session. 
Another objective of the present invention is to provide an interface that appears as 
an ATM interface to applications. 

[001 0] Still further features and advantages of the present invention are identified in the 
ensuing description, with reference to the drawings identified below. 

Brief Description of the Drawings 

[0011] 

The purposes and advantages of the present invention will be apparent to those of 
ordinary skill in the art from the following detailed description in conjunction with the 
appended drawings in which like reference characters are used to indicate like 
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elements, and in which: 



[0012] Figure 1 is a block diagram illustrating a system adapted to provide a virtual PPPoE 
session to a non-PPPoE client in accordance with at least one embodiment of the 
present invention; 

[001 3] Figure 2 is a block diagram illustrating a gateway of the system of Figure 1 in 
greater detail in accordance with at least one embodiment of the present invention; 
and 

[0014] Figure 3 is a block diagram illustrating a method for routing packets internal to a 
gateway based on one or more properties of the packets in accordance with at least 
one embodiment of the present invention. 

Detailed Description of the Preferred Embodiments 

[001 5] Figures 1-3 illustrate a method and a system for providing a virtual point-to- 
point over Ethernet (PPPoE) session between a client unable to support a PPPoE session 
and an access concentrator that prefers or requires a PPPoE session. In at least one 
embodiment, a gateway situated between the client and the access concentrator acts 
as a proxy PPPoE client between the client and the access concentrator, thereby 
allowing the client to send and receive data to/from the gateway in a protocol 
supported by the client, and the gateway provides this data to the access concentrator 
through a PPPoE session initiated and maintained by the gateway. Likewise, data from 
the access concentrator to the client are transmitted through the PPPoE session to the 
gateway, and the gateway encapsulates the data using a protocol supported by the 
client and then forwards the encapsulated data to the client. Additionally, in at least 
one embodiment, the gateway is adapted to allow other clients that are PPPoE-enabled 
to establish PPPoE sessions directly with an access concentrator via the gateway 
concurrently with non-PPPoE clients. 

[001 6] Referring now to Figure 1 , a system for providing a virtual point-to-point over 
Ethernet (PPPoE) session between an access concentrator and a non-PPPoE client is 
illustrated in accordance with at least one embodiment of the present invention. The 
term non-PPPoE, as used herein, refers to a protocol or format other than a PPPoE 
protocol or format, such as an Internet Protocol (IP). Likewise, the term non-PPPoE 
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client, as used herein, refers to a client that, for any reason, is incapable of supporting 
a PPPoE session. Various reasons for why such a client is incapable of supporting a 
PPPoE session include a lack of the appropriate software, limited client resources, 
prohibitive cost of PPPoE software/hardware, legacy operating systems that are 
difficult to retrofit to support PPPoE standards, and the like. 

[001 7] In the illustrated embodiment, the system 1 00 includes a gateway 11 0, an access 
concentrator 1 50, a network 1 20, and at least one client 1 32. The system 1 00 further 
can include at least one client 131. The gateway 1 1 0 can include any of a variety of 
devices used as gateways or interfaces between different networks or network 
components, such as a router, gateway, access point, digital subscriber line (xDSL) 
modem, cable modem, and the like. For ease of discussion, the gateway 1 1 0 will be 
discussed herein in the context of a DSL modem, also known as an asynchronous DSL 
termination unit - remote (ATU-R). The access concentrator 1 50 can include any of a 
variety of devices adapted to provide network access to one or more remote clients, 
such as a remote access server or server application, a DSL access multiplexer 
(DSLAM), an asynchronous DSL termination unit - central (ATU-C), a service provider, 
a modem or modem bank, and the like. The network 1 20 can include any variety and 
combination of communications networks, such as a local area network (LAN), a wide 
area network (WAN), a private network, the internet, and the like, and may include a 
combination of wireless and land-based networks. Alternatively, in at least one 
embodiment, the network 1 20 can include other types of connections, such as a 
universal serial bus (USB) connection, without departing from the spirit or the scope of 
the present invention. For ease of discussion, a preferred embodiment wherein the 
network 1 20 includes a LAN utilizing an Ethernet protocol is discussed herein. The 
clients 1 3 1 , 1 32 can include any of a variety of networked information handling 
devices, such as a personal computer, a laptop computer, a networked personal 
digital assistant, a wireless phone, and the like. 

[001 8] | n at | east one embodiment, the system 100 is utilized to facilitate concurrent 

communication between the clients 131, 1 32 and a network 160 via the network 120, 
the gateway 1 1 0 and the access concentrator 1 50, where the network 1 20 can include 
any of a variety of networks, such as a LAN, a WAN, a private network, a wireless 
network, a private netowork, the Internet and the like. To illustrate, the clients 131 , 
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132 can include personal computers (PCs) used to navigate the Internet (one 
embodiment of network 1 60), such as by browsing the World Wide Web (WWW) using a 
hypertext markup language (HTML) browser installed on the clients 131,1 32. In this 
example, the clients 131, 132 can submit web page requests to servers on the 
Internet via a DSL modem (one embodiment of gateway 1 1 0) and the access 
concentrator 1 50. Data representing these requests is first transmitted from client to 
the DSL modem, where the data is encapsulated in compliance with a protocol, such 
as a RFC 1483-compliant protocol, appropriate for transmission via the transmission 
medium, such as the plain old telephone system (POTS), between the gateway 1 10 and 
the access concentrator 1 10. The DSL modem then transmits this encapsulated data 
through an asynchronous transfer mode (ATM) permanent virtual circuit (PVC) to the 
access concentrator 1 50. The access concentrator 1 50 then can 
deencapsulate/encapsulate the data, if necessary, and transmit the data over the 
Internet to one or more intended data servers. Likewise, the requested web page data 
from a data server is provided to the clients in a reverse manner. 

: i [001 9] In at least one embodiment, the data transmitted between the gateway 1 1 0 and 

the access concentrator 1 50 preferably is sent as part of a PPPoE session, whereby the 
data is encapsulated in accordance with a PPPoE-compliant protocol. This 
arrangement has a number of advantages for an operator of the access concentrator 
1 50. For one, PPPoE sessions typically allow the operator to determine the connection 
time of each client, thereby allowing for client billing based on usage. Likewise, since 
the client typically logs on each time the client uses access concentrator 1 50 to 
initiate a PPPoE session, the access concentrator can dynamically assign IP addresses, 
thereby more efficiently utilizing an assigned block of IP addresses, which often are a 
scant resource. 

In order to establish a PPPoE session between a client and the access concentrator 
1 50, known systems typically include clients having software /hardware adapted to 
support PPPoE sessions, this software/hardware also known as a PPPoE client. Using 
the PPPoE client operating on the client, the client initiates a PPP session with the 
access concentrator via a gateway. The data to be sent to the access concentrator is 
encapsulated in PPP frames and a PPPoE header and/or other appropriate data is 
added to PPP frames to generate PPPoE-compliant frames. The PPPoE frames then are 
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transmitted to a gateway, which then routes the PPPoE frames to the access 
concentrator. Likewise, the access concentrator returns data meant for the PPPoE- 
enabled client as PPPoE frames, where the PPPoE client on the client strips the PPPoE 
and PPP header/other data to extract the encapsulated data meant for the client. The 
client 131 illustrated in Figure 1 is intended to represent such a PPPoE-enabled client. 
The client 131 typically includes a networked processing device adapted to support a 
PPPoE session with the access concentrator 1 50 via the gateway 1 1 0. For example, the 
client 131 could include a personal computer operating PPPoE client software. 

[0021] Unlike the client 131, in the illustrated embodiment, the client 132 includes a 
networked processing device that does not have the capacity to support a PPPoE 
session with the access concentrator 1 50 (herein referred to as a non-PPPoE client). 
This could be for any number of reasons, such as limited computing resources, 
incompatibility of available PPPoE client software with the underlying architecture of 
the client 1 32, or a prohibitive cost of implementing a PPPoE client on the client 1 32. 
Regardless of the reason, without the ability to support a PPPoE session when required 
by the access concentrator 1 50, the non-PPPoE client 1 32 typically would be unable 
communicate with the access concentrator 1 50 using known systems and methods. 
However, in accordance with at least one embodiment of the present invention, the 
gateway 1 1 0 includes a mechanism to provide a virtual PPPoE session 1 40 between 
the client 1 32 and the access concentrator 1 50, thereby allowing the client 1 32 to 
communicate with the access concentrator 1 50 via the gateway 1 1 0 even though the 
client 1 32 is not adapted to support a PPPoE session. 

[0022] , n at jeast one embodiment, the virtual PPPoE session 140 allows the client 132 to 
transmit data to the gateway 1 1 0 using a protocol supported by the client 1 32, such 
as an internet protocol (IP). In turn, the gateway 1 1 0, as a proxy for the client 1 32, 
initiates a PPPoE session with the access concentrator 1 50. The client 1 32 provides 
data to the gateway 1 1 0 in a format supported by the client 1 32 and the gateway 1 1 0 
encapsulates this data into PPPoE-com pliant frames and provides these PPPoE frames 
to the access concentrator 1 50. Likewise, the access concentrator 1 50 provides data 
intended for receipt by the client 1 32 as PPPoE-compliant frames to the gateway 110. 
The gateway 1 1 0 then deencapsulates the data of the PPPoE frames and then 
encapuslates the data into using a protocol supported by the client 1 32 and provides 
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these reencapsulated frames to the client over the network 120. Accordingly, by 
providing this virtual PPPoE session 140 between the client 132 and the access 
concentrator 1 50, the gateway 1 1 0 can satisfy the different communication formats of 
both the access concentrator 1 50 (PPPoE) and the client 1 32 (non-PPPoE) without 
necessitating the installation of additional software or hardware on either end, thereby 
allowing non-PPPoE enabled clients to communicate with the access concentrator 1 50. 

[0023] Referring now to Figure 2, one exemplary configuration of the gateway 1 1 0 is 

illustrated in greater detail in accordance with at least one embodiment of the present 
invention. The gateway 1 1 0, as illustrated, includes at least one client interface 21 0, a 
bridge 220, a concentrator interface 245, an IP stack 250, a frame reflector 290, and a 
virtual PPPoE stack 295. Other components common to gateways, such as power 
supplies, processors, and data buses, are omitted for ease of illustration. Although 
the client interface 210 can include any of a variety of communications interfaces, in 
the illustrated embodiment, the client interface 210 includes an Ethernet-compliant 
interface The bridge 220 can include any of a variety of bridges implemented in 
software, hardware, or a combination thereof. For example, the bridge 220 can 
include a transparent bridge, a spanning tree bridge, and the like. The concentrator 
interface 245 can include any of a variety of communications interfaces compatible 
with access concentrators, or a combination thereof. 

[0024] In the illustrated embodiment, the concentrator interface 245 includes a RFC 1483 
interface 230 and a UTOPIA interface 240 to provide a digital subscriber line (xDSL) 
connection between the gateway 1 1 0 and an access concentrator. In the event that a 
plurality of access concentrators are interfaced using the gateway 1 1 0, the gateway 
1 1 0 can include a single concentrator interface 245 to interface with all respective 
access concentrators or the gateway 1 1 0 can include multiple concentrator interfaces 
245, each to interface with one or more of the plurality of access concentrators. The 
PPPoE stack 295, in one embodiment, includes a PPP client layer 260 and a PPPoE 
client layer 270. 

[0025] 

As discussed previously, in at least one embodiment, the clients 131, 1 32 utilize 
the gateway 1 1 0 to interface in a bi-directional manner with one or more access 
concentrators and the one or more networks connected to the one or more access 
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concentrators. The hatched line 21 1 illustrates essentially a direct, uninterrupted data 
flow path between the client 131 and one or more access concentrators through 
gateway 1 1 0. The solid line 212 illustrates a flow path between the client 1 32 and one 
or more access concentrators via the gateway 1 1 0, wherein the bridge 220 routes data 
through the PPPoE stack 295 for any necessary deencapsulation/encapsulation. 

[0026] The client 1 31 , which is adapted to support a PPPoE session, can initiate such a 
session with an access concentrator via the gateway 110 and forward all outgoing 
data to the access concentrator using the gateway 1 1 0 and receive all incoming data 
intended for the client 131 through the gateway 1 1 0 via the PPPoE session. As 
illustrated, because the data to/from the client 1 31 is encapsulated in compliance 
with a PPPoE protocol, the data generally can be forwarded between the client 
interface 21 0 and the concentrator interface 245 by the bridge 220 without any 
additional modification or encapsulation by the gateway 1 1 0 to ensure that the data is 
PPPoE-compliant. 

[0027] Accordingly, for an incoming PPPoE frame from the client 1 31 , the bridge 220 

forwards the PPPoE frame to the concentrator interface 245, wherein it is encapsulated 
in accordance with the RFC 1483 specification by the RFC 1483 interface 230, 
formatted at the physical layer by the UTOPIA interface 240 for transmission over a 
DSL medium, and then transmitted for reception by the access concentrator. Likewise, 
data intended for the client 1 31 is transmitted as one or more PPPoE frames to the 
gateway 1 1 0 via the concentrator interface 245, and provided to the bridge 220. The 
bridge 220, noting the destination of the PPPoE frame, forwards the PPPoE frame to 
the client interface 210, wherein the PPPoE frame then is forwarded to the client 131 
for processing. 

[0028] 

Since the client 1 32 is unable to directly support a PPPoE session, data from the 
client 132, in one embodiment, takes a different path between the client interface 210 
and the concentrator interface 245 compared to data from the client 1 31 . Accordingly, 
the client 1 32 provides data to the client interface 11 0 in a non-PPPoE format, such as 
an IP packet encapsulated in an Ethernet frame (IPoE). The client interface 1 1 0 passes 
the frame to the bridge 220. The bridge 220 then can extract the IP packet from the 
frame and forward the IP packet to the IP stack 250 rather than to the concentrator 
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interface 245. The IP stack 250, noting the destination address of the IP packet, 
forwards the IP packet to the PPPoE stack 295. As such, the IP stack 250 acts as a 
router between the bridge 220 and the PPPoE stack 295 by routing the IP packet to the 
PPP client layer 260, wherein the IP packet is encapsulated in a PPP frame. The PPP 
frame is then provided to the PPPoE client layer 270, wherein a PPPoE header and any 
other necessary data are added to the PPP frame to generate a PPPoE-com pliant 
frame. Some or all of the elements of the PPPoE stack 295 preferably are implemented 
as a protocol stack or device driver, similar to a TCP/IP protocol stack, an Ethernet 
driver, and the like. Implementation of such protocol stacks is well known to those 
skilled in the art. 

[0029] The PPPoE frame is then provided to the frame reflector 290. The frame reflector 
290, in one embodiment, attaches to the bridge 220 with a MAC address. Accordingly, 
5 frames can be provided from the bridge 220 to the PPPoE stack 295 using the frame 

OS reflector 290. Likewise, the frame reflector 290, in one embodiment, provides frames 

7a from the PPPoE stack 295 to the bridge 220, whereupon the packets are provided to 

ft the concentrator interface 245 for any necessary encapsulation and subsequent 

f|j output to the intended access concentrator. 

[0030] Conversely, in at least one embodiment, a PPPoE frame transmitted from an access 
p concentrator destined for the client 132 is received by the concentrator interface 245, 

Q whereupon it is provided to the bridge 220. The bridge 220, noting the intended 

l|J destination, forwards the PPPoE frame to the frame reflector 290. The frame reflector 

290, by attaching to the bridge 220 with a MAC address, can act as a conduit between 
the bridge 220 and the PPPoE stack 295, provides the packet to the PPPoE stack 295. 
The PPPoE stack 295 then can extract the encapsulated IP packet from the PPPoE 
frame using the PPPoE client layer 270 and the PPP client layer 260. The IP packet then 
is provided to the IP stack 250. The IP stack 250, noting the intended destination of 
the IP packet, routes the revised packet to the bridge 220. The bridge 220 then 
forwards the packet as a frame to the client interface 210. The client interface 21 0 
performs any necessary encapsulation of the frame and then transmits it over an 
Ethernet-based transmission medium (one embodiment of the network 1 20 of Figure 
1) for reception by the client 1 32. Although the PPPoE header and the PPP format data 
typically are removed from the frame before it is provided to the client 1 32, in some 
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instances, the PPP data may be retained in the frame as it is provided to the client 
132. 

[0031] Prior to transmission of data between the gateway 1 1 0 and the access 

concentrator 150 on behalf of the client 132, in one embodiment, the PPP client layer 
260 initiates a PPPoE session with the access concentrator 1 50 for the client 1 32. As 
part of the PPPoE discovery stage, the access concentrator 1 50 can generate a unique 
session ID associated with the client 1 32 and provide this session ID to the PPP client 
layer 260. This session ID can be associated with each subsequent outgoing frame 
processed by the PPP client layer 260 for the client 1 32. Using this unique session ID, 
the PPP client can be adapted to initiate and maintain multiple PPPoE sessions on 
behalf of multiple clients 132. Each client 132 is given a unique session ID that can be 
used by the access concentrator 1 50 and the PPP client layer 260 to determine the 
source/destination of a particular frame. Mechanisms for initiating and maintaining 
single and multiple PPPoE sessions are known to those skilled in the art. 

[0032] By using the bridge 220, the frame reflector 290, and the PPPoE stack 295 to 
provide a virtual PPPoE session between the client 1 32 and the access concentrator 
1 50, the gateway 1 1 0 can encapsulate data from the client 1 32 to be compatible with 
the PPPoE protocol and then provide the encapsulated data to an access concentrator 
while allowing PPPoE-conformant data from the client 131 to be transmitted to the 
same and/or different access concentrator(s) with minimal processing. Likewise, an 
access concentrator can provide data intended for receipt by the client 1 32 to the 
gateway 1 1 0 as PPPoE frames, whereupon the gateway 1 1 0 deencapsulates the PPPoE 
frames to generate non-PPPoE (e.g., IP) packets having a format supported by the 
client 1 32. Each of the bridge 220, the frame reflector 290 and the PPPoE stack 295 
can be implemented as executable instructions, hardware, or a combination thereof. 
For example, the PPPoE stack 295 and frame reflector 290 could be implemented as 
software executed on a processor associated with the gateway 1 1 0, and the bridge 
220 could be implemented as a hardware device. 

[0033] 

Referring no w to Figure 3, a scheme for routing frames through the gateway 1 1 0 
is illustrated in accordance with at least one embodiment of the present invention. As 
discussed previously, in at least one embodiment, the path through the gateway 1 1 0 
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taken by data to/from the client 1 31 is different than the path taken by data to/from 
client 1 32 since the client 1 3 1 is capable of supporting a PPPoE session while the 
client 1 32 is not. Accordingly, in at least one embodiment, the bridge 220 determines 
the route taken by a frame based on one or more properties of the frame, such as the 
destination media access control (MAC) address of the frame. 

[0034] As illustrated in Figure 3, data (in the form of a frame or other logical segregation 
of data) is provided by the each of clients 131, 132 to the client interface 210, 
encapsulated/deencapsulated (if necessary), and then forwarded to the bridge 220. 
The bridge 220 then decapsulates the one or more frames into one or more packets 
and forwards the one or more packets to either the concentrator interface 245 or the 
IP stack 250 based on the destination MAC addresses of the one or more frames. In 
one embodiment, frames having a destination address other than a MAC address of 
an interface to the bridge 220 are forwarded to the appropriate interface for 
transmission to the desired destination. However, frames having a destination MAC 
address of one or more of the interfaces attached to the bridge are automatically 
forwarded to the IP stack 250. To illustrate, assume that client 131 has MAC address 
A, client 1 32 has MAC address B, the client interface 21 0 has MAC address C, the 
concentrator interface 245 has MAC address D, the frame reflector has a MAC address 
E attached to the bridge 220 and a MAC address F attached to the PPPoE stack 295, 
and the access concentrator 1 50 has the MAC address C. As illustrated in Figure 3, the 
interfaces to the bridge 220 have MAC addresses C (concentrator interface 245), D 
(concentrator interface 245), and E (frame reflector 290). Accordingly, in one 
embodiment, any frame received at the bridge 220 that has a destination MAC 
address of C, D, or E is automatically forwarded by the bridge to the IP stack 250. 
However, frames having destination MAC addresses other than MAC address C, D, E 
are forwarded by the bridge 220 to the appropriate interface for transmission to the 
component having the destination MAC address. By forwarding frames in this way, the 
packets from the client 131 and client 1 32 can be processed by the gateway 1 1 0 as 
necessary. 

[0035] To i|| us trate, in one embodiment, when the client 1 31 initiates a PPPoE session, it 
determines the MAC address of the access concentrator 1 1 0, such as by transmitting 
a broadcast request for any available access concentrator. Accordingly, any 
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subsequent frames transmitted from client 131 intended for the access concentrator 
1 1 0 are have a destination MAC address of the MAC address G of the access 
concentrator. When the bridge 220 receives frames from the client 131, the bridge 
220, in one embodiment, forwards the frames to the concentrator interface 245 since 
the bridge 220 knows, based on a forwarding table and the like, that the concentrator 
interface 245 is used to transmit frames having a destination MAC address G (of the 
access concentrator 1 50). Likewise, frames transmitted from the access concentrator 
1 50 to the client 131 have the destination MAC address A of the client 131. 
Accordingly, when the frames are received at the concentrator interface 245 and 
provided to the bridge 220, the bridge 220 forwards the frames to the client interface 
210 since the bridge 220 knows, via a forwarding table, that the client interface 210 is 
used to transmit frames having the destination MAC address A or B. 

[0036] However, since the non-PPPoE client 1 32 is unable to determine the MAC address 
of the access concentrator 1 50, the client 1 32 treats the gateway as a router and 
transmits frames intended for the network 1 60 the client interface 210, where the 
frames have a destination MAC address C (of the client interface 210). The client 
interface 210 decapsulates the frames, if necessary, and provides the frames to the 
bridge 220. Since the destination address of the frames remain unaltered and are 
therefore still addressed to MAC address C, the bridge 220 automatically 
deencapsulates the frames into packets and forwards the packets to the IP stack 250 
since MAC address C of the frames/ packets is the MAC address of an interface 
attached to the bridge. 

[0037] The |p stack 250, noting the destination IP address of the packets, routes the 

packets to the PPPoE stack 295, whereupon the packets are encapsulated into PPPoE- 
compliant frames having the destination MAC address G of the access concentrator 
1 50 and provided to the bridge 220 via the frame reflector 290. Because devices 
attached to the bridge 220 typically are required to have MAC addresses which are 
used by the bridge 220 to forward packets, the frame reflector 290, in one 
embodiment, supplies a MAC address E to the bridge 220 when the frame reflector 
290 attaches to the bridge 220 and a MAC address F to the PPPoE stack 295. The 
frame reflector 290 can be implemented as a hardware device, thereby having an 
actual MAC address. Alternatively, in one embodiment, the frame reflector 290 is 
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implemented as executable instructions, such as a device driver, that simulates a 
hardware device by providing a simulated MAC address to the bridge 220. 
Mechanisms and methods to simulate a hardware device using a simulated MAC 
address are known to those skilled in the art. 

[0038] Alternatively, rather than routing the packets based on their destination IP 

addresses, the IP stack 250 can be adapted to route any packet received from the 
bridge 220 to the PPPoE stack 295 by default. The bridge 220, noting that the 
destination MAC address of the frames is MAC address G and not MAC addresses C, 
D, or E, forwards the frames to the concentrator interface 245, the bridge 220 
forwards the frames to the concentrator interface 245 associated with the access 
concentrator 1 50 for transmission to the access concentrator 1 50. 

[0039] Conversely, frames intended for the client 1 32 from the access concentrator 1 50 
have the destination MAC address F of the frame reflector 290. Upon receipt of these 
frames, the concentrator interface 245 provides the frames to the bridge 220. The 
bridge 220, based on the destination MAC address F of the frames, forwards the 
frames to the frame reflector 290, since the frame reflector 290 is associated with 
MAC address F in the forwarding table of the bridge 220. The frame reflector 290 
receives the frames from the bridge 220 and forwards them to the PPPoE stack 295. 
The PPPoE stack 295 deencapsulates the frames, removing the PPPoE/PPP header(s) 
and associated data, and provides the resulting frames to the IP stack 250. The IP 
stack 250, having MAC address information of locally-connected hosts to the gateway 
1 1 0 (i.e., clients 1 3 1 and 1 32) and noting the intended destination (client 132), 
assigns the MAC address A to the destination MAC address of the packets, 
encapsulates the packets as frames, and routes the frames to the bridge 220. The 
bridge 220 then forwards the frames to the client interface 210 based on the 
destination MAC address A of the frames and the forwarding table of the bridge 220. 
As a result, both PPPoE clients and non-PPPoE clients may use the gateway 1 1 0 to 
communicate with a network via one or more access concentrators. 

[0040] 

Other embodiments, uses, and advantages of the invention will be apparent to 
those skilled in the art from consideration of the specification and practice of the 
invention disclosed herein. The specification should be considered exemplary only, 
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and the scope of the invention is accordingly intended to be limited only by the 
following claims and equivalents thereof. 
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